A PTT call service provides various types of call services such as one on one (1-1) calls, prearranged talk group calls, chat group calls, and adhoc group calls. Stringent call setup time restrictions and unique service usage patterns make PTT call service very different from a conventional voice over internet protocol (VOIP) call service.
In most IP network topologies, significant cost is incurred in terms of latency and core network resource usage (network address translation (NAT) ports, session border controller (SBC) sessions, etc.) when setting up an IP path between a client residing on a user device and the server. This is due to the fact that IP networks are protected by different types of demilitarized zone (DMZ) appliances, such as NAT, firewall, SBC, load balancers, etc. In such environments, it may be necessary to build in NAT/firewall traversal mechanisms using suitable protocols (e.g., session traversal utilities for NAT (STUN) and traversal using relays around NAT (TURN)), use appropriate application protocols to open interfaces on SBC, and the like. Setting up secure communication paths often involve key exchange mechanisms, which adds to the latency cost and consumes resources in network equipment used for secure sockets layer (SSL)/transport layer security (TLS) offloading. Therefore, in environments where the connection setup latency is affecting the service usability, persistent pre-established sessions between the client and PTT server can be used to avoid or at least reduce call setup delays.
With recent advances in technology, it is now desirable to deploy several services in virtualized environments that support elastic scalability and facilitate rapid deployment through agile continuous integration procedures. However, it is challenging to realize the benefits of elastic scaling by applying these methods to a PTT service because PTT services rely on persistent long-running pre-established connections and sessions for effective service delivery. Furthermore, carrier grade PTT service deployments may have stringent service availability requirements and are usually required to support geographical redundancy (e.g., geographically distributed multi-site deployments).
Further, in a distributed architecture, communications between PTT users may result in PTT pre-established session setup with different PTT call servers. Additional signaling may result to connect these users across different PTT call server instances, which causes additional latency, particularly in shared cloud infrastructure environments where the network is not specifically optimized for meeting the PTT call service requirements. For a service, like a PTT service, which has to overcome the RAN latencies and still meet the stringent sub-second call setup requirements, even milliseconds of additional latency can negatively impact service. Thus, it is desirable to organize communication paths to avoid extra hops.